CD 



WO(U.D r>rreLLECTUAL PROPERTY ORGANIZATION 
Intemaiiocul Bureau 




PCT 

INTERNATIONAL APPLICATION PUBUSHED UNDER THE PATENT COOPERATION TREATT (PCD 



(51) International Patent CUsslflcaUoo ^ 
G06F 9/44 



Al 



(11) International Publkatioo Number: WO 96A8947 

(43) International Publication Date: 20 June 1996 (20.06.96) 



(21) International AppiicaUon Number: PCT/US95/ 15959 

(22) Interaatlonfll Filing Date: 12 December 1995 (12.12.95) 



(30) Priority Data: 

08/355.356 



13 December 1994(13.12.94) US 



(71) AppUcant (for all de signaled Suites except US): NOVELL, 
INC. [USAJSl; 1555 Nonh Technology Way. Orcm. UT 
84057 (US). 

(75) ta^tor/Aj!pilcant (for US only): OLDS. Dale, R. (US/US]; 
1623 East Edgccliff Drive. Sandy. UT 84092 (US). 

(74) Aflent: MESSENGER. Emamaric: Novell, Inc., 1555 North 
Technology Way. M/S A232, Orem, LTT 84057 (US). 



(81) Designated Stotes: AM, AT. AU, BB. BG. BR. BY. CA. CH, 
OvTc^, DE, DK. EE. ES. R. GB. GE HU. IS. JP. KE. 
KG. KP. KR. KZ LK. LR, LT, LU. LV. MD. MG. MN. 
MW, MX, NO, N7. PL. FT. RO. RU, SD. SE. SG. SI. SK. 
TJ. TM. TT. UA. UG, US, UZ, VN. European patent (AT, 
BE CH, DE DK, ES. FR. GB. GR. IE IT, LU. MC, NL, 
PT. SE). OAP! patent (BF. BJ. CF, CG. CI. CM. GA. GN. 
ML, MR, NE, SN, TD. TG). ARIPO patent (KE LS. MW. 
SD, SZ, UG). 



Published 

With intemationai search report. 

Before the expiration of the time limit for amending the 
ciaims and to be republished in tht eveni of the receipt of 
amendments. 




(54) Title: 




,A AT 

Partition n PirtitkmE — 



Typical Directory Tree 

(57) Abstract 

service, compu«r prop^n » d««nnne '^ll^^^^'^^.^Z'^ ^TdSo « aS^S^S Z r^T^^roc^ or 



3NSCOCIO:<WO 9«1»47A1>' 



FOR THE PURPOSES OF INFORMATION ONLY 



Codes used to identify States party to the PCT on the front pages of pamphlets publishing international 
applications under the PCT. 



AT 


Austria 


AU 


Auscnlia 


BB 




EC 


Belfiun 


BT 


Burtma Fuo 


BC 


Bulfiru 


BJ 


Benin 


BR 


Bruil 


BY 


BcUius 


CA 


CamcU 


CF 


CeaomJ Africm Republic 


CC 


Congo 


CH 




CI 


COu d'lvotre 


CM 


Cvnenion 


CN 


China 


CS 


CudMilovikia 


C2 


Cifldi Republic 


DE 


GciniMif 


DK 


Oenmarfe 


E5 


Spain 


n 


Fmlmd 


FR 


Franca 


CA 


Gabon 



GB 


Uaked Kingdom 


CE 


Geor|U 


CN 


Guinea 


GR 


Greece 


HU 


HuBgaxy 


IE 


Inland 


IT 


Ualy 


JP 


Japan 


KE 


Ker.yi 


KG 


Kyrgyiun 


KP 


Democruic People's Republic 




of Kotrt 


KR 


RtpuMk of Korea 


fa 


Kaiakhstan 


u 


LiectKcnstcm 


uc 


Sri Lanita 


IV 


Luaembouit 


LV 


Lafvta 


MC 


Monaco 


MO 


Republic of Moldovi 


MC 


Madagascar 


ML 


Mali 


MN 


Mongolia 



MR 


Mauritania 


MW 


Malawi 


.NE 


Niger 


NL 


NctheriaKls 


NO 


Nofway 


sz 


New Zealand 


PL 


Poland 


PT 


Ponugai 


RO 


Romania 


RU 


Russian Fedemioo 


SO 


Sudan 


SE 


Sweden 


SI 


Sbvenia 


SK 


Slovdtta 


5N 


Senegal 


TO 


Chad 


TO 


Togo 


TJ 


Tajikiauti 


TT 


Trinidad and Tobago 


UA 


Ukraine 


US 


Unitnd StaMa of America 


vz 


Utbekmm 


VN 


Viet Nam 



wo 96/18947 



PCT/US95/15959 




Figure 1 - Computer Object & Associated Attributes 




9«18947A1> 



wo 96/18947 



PCT/US95/15959 



RIP 

Routing 
Information 
Protocol 



SAP 
Service 
Advertising 
Protocol 



N LSP 
NetWare Link' 
Services 
Protocol 



NDS 
NetWare 
Directory 
Services 



NCP 
NetWare 

Core 
Protocol 



IPX 

1 nteme tworic P acke t Exchang e 



LAN Links 



WA N Links 



Figure 3 - NetWare Protocols 



2/3 



JNSOOC10:<WO 9«t9947A1> 



wo 96/18947 



PCT/US95yi5959 




IThrMd Abort 
Signal. R*rwn« 
DSOL0XU41D 
OS>a.M.tf 
Convnlt* TwTTwicBB 
Jfwmmi 



Figure 4 - Dynamic Update Algorithm 



3/3 



tNS0OC;0:<WO 9«t8947Ai> 



INTERNATIONAL SEARCH REPORT 



lAGtnuQOfit' Tiiuaon No 

PCT/US 95/15959 



A. Cl^SSlFICATTON OF SUBJECT MATTER 

IPC 6 G06F9/44 



AccotAth to biOTiiaorui p4tcm QAnfiotton (IPO or to boch luaonM dusdcAQon And IPC 



B. FIELDS SEARCHED 



IPC 6 G06F nc«on fymooM) 



OocwTwnuoon KireM otticr than (rammum dooAacnuoon to the encnc ttut mch docunems art included in the 



ficldi 



El«c»onie dau base conutud dunng the imcmasonat MafciKnaac ofdau bajt awl. wtm pracncai, tcar^ ecnm wd) 



C. DOCUMENTS CONSIDERED TO BE R£L£VaNT 



Cait^ry * Guooa of document, mm inAcaaor. •^hat appropnatt. of dw rajcvant 



Rckvam to daon No. 



PROCEEDINGS OF THE INTERNATIONAL SYMPOSIUM 
ON FAULT TOLERANT COMPUT (FTCS), TOULOUSE. 
JUNE 22 - 24. 1993, 
no. SYMP. 23. 22 June 1993, INSTITUTE OF 
ELECTRICAL AND ELECTRONICS ENGINEERS, 
pages 30-35. XPe03437223 
DEEPAK GUPTA ET AL: 'INCREASING SYSTEM 
AVAILABILITY THROUGH ON-LINE SOFTWARE 
VERSION CHANGE* 
see abstract 

see page 30, left-hand colunr, line 1 - 
line 19 

see page 31, left-hand colunr, line 2 - 
1 i ne 10 

see page 33. left-hand colurm, line 1 - 
right-hand colunn, line 33 ~" 



-/-- 



1-16 



I X| ^urdM> finngntnfi an liAed a 4w < 



aon oC box C. 



0 



t fanaJy 



Spccul cattfona of oicd dnnwMntt : 

•A' docwnonc Mam^ m« fcacni «au of tfw i.- ^ch u not 
coai^wd to bi of pvacular Rlcvmcc 

E' earlier docunou but puUt^wd oo or aAcr :^ . nmaQoaal 
rdiQK dale 

'V tetsBcot vtiKh may Qvow douMi on pnor.tv i^s) or 
whiA a oicd ID auMah (he puUicaaoa >uu' ->* taaOm^ 
ataaon or oite sptcul mm (as ^eafi&s: 
*0' documcm rcfcmiig lo an oral dtadonra, tae. enbnon or 



T" laser dooimott puMiM alter Ac tnicnaaonal fihnc date 
or ^mty dace and not ta oooAict mdi ih« appacason but 
ated ID uBdemaad the pnnaple or theory w»dcr1yin« Qte 



P* finnemnr . p u hbtft ed pnor to die inieraaaooai (um daM but 
later than the pnortty date claimed 



X do rnm l of paroeuUr rdevanee; the dauncd invcnbon 
caoM be con a deted aovd or cannot be conAdercd e 
arfokm en ta^«m«e «^ vhea (he ■^it iiri a takn aioM 

'Y* dnnawm of perQcutar relevnnoe; dM datiaed umnaon 
canooe be cundd er m to mvolve an mymm Aqp when tht 
d o c ^ aa ei i t a oominned wiih one or man other luch doeu- 
imaa. eotntenaaon bsn( obvious to a person ^Ucd 
(A die aft. 

A* dn oan r w member of the lamt pdtcnt ftmly 



Dace of acnial compteoon of tht munuaonal MarcA 

8 May 1996 


Dale of madtni of the intemaoonaJ search rrport 

22.05.96 


Name and tnatUnt ad*en of the ISA 

Ei«oqean Patent Omcc P.B. illt Patendaan 2 
NL . 2m HV Riisvt* 
Td.(-p JI.70) WaXOcTx. 31 6Sl cpo nl. 
FaJC(*J|.70) 340-1014 


Auiharued ofTica' 

Michel, T 



page 1 of 2, 



tNSOOCiO: <W0 9«18947A1> 



INTERNATIONAL SEARCH REPORT 

"documents cons idered to be relevant 

DATA COMMUNICATIONS INTERNATIONAL. OCT. 
USA 

iol 21. no. 13. ISSN 0363-6399 
pages 53-56, 58, 60. XP0005691O5 
RUIZ B ET AL: "Netware 4.0: a directory 
to the enterpri se" 

see page 56, middle column, line 3 - page 
58. left-hand colunr. line 34 
see page 58. right-hand column. Vine Zl - 
page 60, middle colunn. line 19 

US. A, 5 155 847 (KIROUAC DONALD L ET AL) 
n'october 1992 
see abstract 

see column 1. line 54 - colunr 3. line 4. 
figure 1 

US.A.5 359 730 (MARRON ASSAF) 25 October 
1994* 

see abstract 

see colunr 2. line 53 - column 4, line 2 

. W0.A,94 01819 (ERICSSON TELEFON AB L M) 20 
January 1994 
see the whole document 

EP,A,0 426 911 (HEWLETT PACKARD CO) 15 May 
1991* 

see the whole document 



InuTtuneml >lit«oon So 

PCT/US 95/15959 



1-16 



1-16 



1-16 



1-16 



1-16 



INTERNATIONAL SEARCH REPORT 

IfifarTTu-on on pattnt fimily membcn 



[fiCOTUOorul 1 1 canon No 

PCT/US 95/15959 



Puent documtm 


PublicACion 


P*i«nt family 


Publication 


d£«d in search repori 


date 




dau 


U5-A-5155847 


13-10-92 


CA-A- 1310131 


lG-ll-92 


US-A-5359730 


25-10-94 


NONE 





WO-A-9401819 


20-01-94 


US-A- 


5410703 


25-04-95 






AU-B- 


667559 


28-03-96 






AU-B- 


4516493 


31-01-94 






EP-A- 


0648353 


19-04-95 






FI-A- 


946195 


30-12-94 






NO-A- 


945096 


22-02-95 


EP-A-0426911 


15-05-91 


NONE 







fmm PCT/Ua/211 (pmmt tamutj mmx) |J«Jy ini) 



NSCCCIO:<WO 96f89-7At> 



wo 96/18947 PCr/US95/159S9 

Method & Apparatus To Update or 
Change A Network Directory 

5 Background 

The present invention relates to the management of distributed digital network directories, 
and particularly to providing dynamic updates to the computer programs supporting distributed 
directory services. 

10 Technological advances in miCToelectronics and digital computing systems have resulted in 

the proliferation of digital computer networks, enabling the distribution of networking services 
across a wide range of computers participating in the network and over various communications 
media. Advances in distributing applications have also resulted in a client-server architecture for 
applications. Under the architecture, the portions of the application that interaa with the user arc 

1 5 typically separated from the portions of the application that fulfill client processing requests. 

Typically, the portions of an application that interact with the user are called a client applications 
or client software, whereas the portions of the application that service requests made by the client 
applications are called a server applications or server software. In a network environment, the 
client applications and server applications are generally executed on different computers. 

20 Historically, digul networks in the form of local area networks, a physical collection of 

personal computers interconnected with network cabling and network interface cards, comprised 
a single network server and multiple network clients. To manage which network clients could 
access the network server, as well as what files, printers, printer queues, and server applications 
wei« available to the network clients, the network server naintained information on each of the 

25 resources that were attached to the server, the identities of the network clients and users who 

could use the services of the network server, and the scope and nature of the services available to 
the network clients and users. 

As local area networks becanw more popular, networks grew in size requiring several 
servers to service the needs of users. With inaeased size and complexity of networks, came the 
30 need for easier management of network servcn. Users required access to an increasing number 
of services that were located on an inaeasing number of network servers. Several vendors began 
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offering networking servers. Each vendor implemented a different scheme of providing 
networking services information. In addidon* because of the way the server maintained 
information about only its networking services, each network server still required management of 
its resources independent of other network servers. 

5 This insular nicihod of maintaining information of networking services fueled research and 

development of distributed networking directories that span networking servers. Thus far, 
research has resulted in several potential solutions. Three technologies currently hold greater 
promise for replacing the large number of insular, idiosyncratic directories that now litter many an 
enterprise's numerous local-area networks and electronic-mail systems. One of the more popular 
10 approaches exploits the X.500 distributed network information directory services protocol 
developed as published by the CCIT and Open Systems Interconnect consortium. 

However, while the X.500 protocol appears to hold the greatest promise to provide a 
robust, distributed directory, the X.SOO protocol has been slow to gain acceptance. The X.500 
protocol has been plagued from the stan with management, interoperability and security 
15 problems. The X.500 protocol specification describes a technical framework, interoperability 
requirements and compliance criteria but does not describe specific implementations. Thus many 
of the details of implementation have been left up to systems providers. 

The X.500 protocol specification describes a distributed directory. The directory provides 
information services to network clients. The information in the directory can be read as well as 
20 modified by users who have applicable access rights. 

The information stored in the directory is stored in the form of a schema, a collection of 
objects with associated attributes or properties tied together by their relationship to each other. 
Figure 1 shows an object called "Computer" with a few associated attributes, such as owner, 
operator, status, etc. The values of the properties arc not shown in the figiu-e but an example of a 
25 value for "Owner" might be "Fred." Objects in the du-eciory and their names correspond to 

things that humans relate to when dealing with computers, namely, users, printers, print queues, 
networks and information. Objects such as countries, organizations, networks, people and 
computers are objects you might find in the directory as well. 
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The directory provides informadon to users by giving users a hierarchical view of all of the 
informarion contained in the directory. The hierarchical view is generally in the form of a tree. 
Figure 2 shows a directory. Each of the branches and terminating points or leaves represent 
objects in the directory. Generally, implementations of the directory organize objects in subtrees, 
5 partitions or domains. Figure 2 also shows the directory organized into partitions or domains. 
Multiple copies of each partition may be stored in the directory. Software schemas define and 
determine the number and types of replicas of each partition. 

Multiple replicas of a partition arc needed to reduce network storage and traffic 
requirements and speed up directory searches. Replicas are stored in name servers. A name 
10 server is a computer in the network, usuaUy a network server. More than one partition can be 
stored in a name server. Partitions stored in a name server need not be contiguous. 

The directory tree provides a logical means of searching for information. The tree is 
generally patterned after logical groupings such as organizations, organizational units, computers 
and users. These logical groupings, while extremely useful in helping users find relevant 
15 information also creates significant problems in managing the directory. 

Each partition forms a major subtree of the directory. Taken together, the partitions form 
a hierarchical tree of partitions that leads back to a root partition containing the root directory. 
Where boundaries of two partitions meet, the partition closer to the root is considered superior, 
and the partition farther from the root is considered subordinate. Thus, Figure 2, partitions E and 
20 C are subordinate to the other partitions. 

The present invention solves one of the problems associated with a distributed directory. 
As distributed directories become more popular, more and more users will rely on them for access 
to data and services. As user rely on directories more heavily, the time in service of the directory 
will be critical. Users will not tolerate even a temporary shut down of the directory or a ponion 
25 of the directory. 



3 
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Summary of the Invention 

With the present invention the computer programs that provide the services associated 
with a distributed directory can be dynamically updated without a significant interruption in 
5 services. Time in service of the directory will thus increase, increasing user confidence in the 
directory. 

Brief Description of the Drawings 

The present invention may be more fully understood by reference to the following 
10 Detailed Description in conjunction with the Drawings, in which: 

Figure 1 shows a typical directory object, a computer, with some of its associated 
attributes; 

Figure 2 shows a typical directory tree; 

15 

• Figure 3 shows the network protocol environment in which the present embodiment of the 
invention is implemented; and 

Figure 4 shows the software algorithm employed by the invention to dynamically update a 
20 directory services module without interruption of services. 

Detailed Description of the Invention 

25 The present embodiment of the invention, Novell's NetWare Directory Service or NDS, 

supports dynamically updating the computer programs that provide distributed digital directories. 
NDS operates in the NetWare network operating system environment. 

The invention is enabled through a NetWare Core Protocol verb. NDS design builds on 
several previously implemented capabilities of NetWare, including the NetWare Core Protocol 
30 C*NCP"). The first capability relevant to the invention is NetWare's native network layer 
protocol, IPX. IPX provides end-io-end datagram delivery over network media and over 
internetworks. 

NDS allows multiple independent name trees to coexist in the same internetwork without 
interfering with each other. A rendezvous feature is defined allowing a client interested in a name 

4 
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tree 10 locate NDS name servers. The rendezvous feature builds on another previously 
implemented capability of NetWare: SAP (Service Advertising Protocol). Routers in all installed 
NetWare internetworks convey SAP information for client/server rendezvous. With NDS, SAP 
has a narrowly confined role: a client uses it to find its first NDS name server. 

5 The NCP sits above the network layer. See Figure 3. NCP supports many networking 

services, such as file services. Certain operations on an NCP connection are specific to NDS. 
Once an NCP connection exists, it can also convey NDS requests and replies. Because NDS uses 
messages that can be quite large, it employs a fragmentation protocol to convey an NDS message 
in (possibly) several NCP packets. 

10 Each NCP packet begins with a small message header that carries general status 

information about the current state of the connection between the client and the server. The client 
request header is seven bytes long, while a server's reply header is eight bytes long. As shown 
below, the RequestTypc variable defuies the type of network request. A type of Ox 1 11 1 is 
reserved for connection allocation services; a type of 0x2222 is reserved for server request 

15 services; a type of 0x3333 is reserved for server responses; a type of 0x5555 is reserved for 
destroying connections; and a type of 0x9999 is reserved for work in progress responses. 

Reload Verb 
0x2222 104 8 

20 Request FormaC ^ - - 



Offset 


Content 




Type 


0 


RequestTypc 


(0x2222) 


WORD 


2 


SequenceNumber 


(UstScq+1) 


BYTE 


3 


ConncctionHigh 


(ScrviceConn) 


BYTE 


4 


TaskNumbcr 


(CuTTcntTaskNum) 


BYTE 


5 


ConnectionLow 


(ServiccConn) 


BYTE 


6 


FunctionCode 


(104) 


BYTE 


7 


SubFuncCode 


(08) 


BYTE 



5 
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Reply Format 



5 



Offset 


Content 




Type 


0 


Reply Type 


(0x3333) 


WORD 


2 


SequenceNumber 


(LastSeq+l) 


BYTE 


3 


ConnectionLow 


(ServiceConn) 


BYTE 


4 


TaskNumber 


(CurrentTaskNum) 


BYTE 


5 


ConnectionHigh 


(ServiceConn) 


BYTE 


(f 


CompletionCode 


(Ccode) 


BYTE 


7 


ConnectionStatus 


(StanjsFlag) 


BYTE 


8 


NDSErrorCode 


(NDSError) 


4 BYTES 


12 


Reserved 




4 BYTES 



] 5 The sequence number maintains a numeric counter for all incoming requests to provide 

reply prioritization. The ConnectionLow and the ConnectionHigh numbers identify a particular 
service connection between the client and the server. The TaskNumber distinguishes which 
client process or thread is making the request to the server. 

The present embodiment of the invention uses the Reload Directory Services NCP. The 
20 Reload Directory Services NCP allows the principal computer program that provides directory 
services in the NetWare environment, DS.NLM, to be replaced on disk and reloaded in a server 
while that server is active and while other computer programs, NetWare Loadable Modules or 
NLMs in the NetWare environment, of the server are actively referencing NDS entry points. 

Three NLMs are involved. The DSLOADER.NLM contains the directory entry points to 
25 which all other NLMs actually link, including the current DS.NLM in memory and a new 
DS.NLM on disk which is to replace the current DS.NLM. 

Referring to Figure 4 and the code segments provided in Tables .... the dynamic update 
aspect of the invention is performed by two threads of execution within the NetWare operating 
system. The first thread (A) is the thread that begins servicing the NCP request, the other thread 
30 (B) is started by thread (A) to complete the reload of the new DS.NLM. The replacement 
algorithm is as follows: 

1 . Thread (A) receives the RELOAD NLM NCP request in a function that is part of the 
currently loaded DS.NLM. 

35 
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2. Thread (A) checks the client authorization. 

3. If the client has proper authorization, usually the highest level of security clearance 
5 allowed by the system, thread (A) calls the DSLOADER and requests a reload. 

4. Thread (A) renames the memory image of the currently loaded DS.NLM to 
DSOLD.NLM. 

10 5. Thread (A) starts thread (B) and then waits until thread (B) reports whether or not the 
load was successful. 

6. Thread (B) calls the operating system to load the new DS.^fLM. This loads the new 
DS.NLM and then calls DS.NLM's initialization function. 

15 

7. While initializing the new DS.NLM, thread (B) reporu the new DS.NLM version number 
to DSLOADER and retrieves from DSLOADER the DSOLD.NLM version number. The 
DSLOADER may reject the load with an error response or it may return the new 
DS.NLM version number. 

8. Thread (B) will abort the load on an error from the loader, or if the new DS.NLM rejects 
the version number returned by DSLOADER. Thread (B) will indicate to thread (A) if it 
aborts or commit to continue the load. 

25 9. Thread (A) detects the abort or commit state transition from thread B. If the load is 
aborted thread (A) renames the DSOLD.NLM back to DS.NLM in memory. It then 
returns from the loader. 



20 



30 



10. The DSOLD.NLM replies to the NCP request. 

11. If Thread (B) commits to continue the load it waits for thread (A) to complete the 
response to the NCP, then it will unload DSOLD.NLM and continue with the initialization 
of the new DS.NLM. 

35 1 2. Thread B terminates itself. 
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10 



15 



20 



Table 1 - Code Segments Implementing Steps 1-3 and 10 
iac ReloadDSiinc conn) 
C 

inc err = 0, managesEntry ; 
THREADDATA td; 

/* 1. begin servicing reload NCP ♦/ 

if (err = DSAClienCStart (TD.CHECK.OPEN, conn, -1, -1, itd) ) 
return err; 

/* 2. check client authorization */ 
if ( IsSupervisor ( conn) 

II ! (err = GlobalCheckManageroent { Server ID () . ID_SELF, 

imanagesEntry , 0) ) 

StSt managesEntry) 
err = DSLReload ( DSModuleHandle ( ) > ; /* 3. call loader •/ 
else if { ! err) 

err = ERR_NO_ACCESS; 

/♦ 10. reply to the NCP •/ 
return DSAClientEnd ( err) ; 
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10 



15 



20 



25 



30 



35 



40 



45 



Table 2 - Code Segments Implementing Steps 4-5 and 9 
inc DSLReload(uint32 moduleHandle) 
( 

/• 4. rename DS.NLM to DSOLD.NLM •/ 

struct LoadDef initionStructure •mh = (struct LoadDef ini tionStructure 
• ) moduleHandle; 

char savedName [sizeo£ (mh->LDFileName) ] ; 
if ( !mh) 

mh = (struct LoadDef initionStructure *) regis teredModule ; 
else if (moduleHandle *.= regis teredModule) 
return ERR_INVALID_REQUEST; 

if (dslState != DSL.IDLE) 

return ERR_DS.LOADER_BUSY ; 
dslState = DSL.ACTIVE; 
if (mh) 



{ 



) 



/* actual rename happens here */ 

CMovB(mh->LOFileName, savedName, sizeof (savedName) ) ; 
CMovB(dyingNLMName, mh->LDFileName, sizeof t savedName) ) 



/* 5. start new thread and wait for state change 
aesReload. AWa)ceUpDelayAmount =0; 
aesReload. AProcessToCall = ReloadWorker ; 
aesReload. ARTag = aesTag; 

ScheduleSleepAESProcessEvent (&aesReload) ; 
while (dslState == DSL.ACTIVE) 
CYieldWithDelay () ; 



/* 9. detect state and rename DSOLD.NLM bacic to DS.NLM if abort */ 
if (dslState DSL.ABORTED) 



( 



if (mh) 
{ 

CMovB ( savedName , mh->LDFileName, sizeof ( savedName ) t 
/* mh->LDFlags i= oldDontUnloadBit ; •/ 

} 

dslState = DSL.IDLE; 
return loadError; 

} 

if (dslState == DSL. PROCEEDING) 
dslStace = DSL.COMMITTED; 
return 0; 
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Table 3 - Code Fragments Implementing Step 6 and part of 8 



void ReloadWorJcer (void) 

{ 

unsigned long oldModule = registeredModule; 
if (dslState 1= DSL_ACTIVE) 
return; 

/* 6. call load function ♦/ 
if (loadError » LoadDSNLMO) 

{ 

/♦ 8. indicate the abort state change ♦/ 
if (dslState DSL^ACTIVi:) 

dalState - DSL ABORTED; 

} 

else if (dslState «- DSL_CORPSE) 

{ 

if (oldModule) 

{ 

DelayMyself (18, timerTag) ; 
KillMe (oldModule) ; 

} 

dslState » DSL_IDLE; 

} 

} 



Table 4 - Code Fragments Implementing Step 7 and the Remainder of Step 8 
int RegisterWithDSLoader (void) 

{ 

int err; 

uint32 dslVersion, loadedDSVersion ; 
int i ; 

/*..-*/ 

/* 7. negotiate versions with loader. Handle loader's rejection ♦/ 
if (err = DSLNegotiateVersions (DSVersion ( ) , idslVersion, 
^loadedDSVersion) ) 

return err; 

if ( ! ACCEPTAaLE_DSLOADER_.VERSION(dslVersion) ) 

return ERR_INVALID_DS_VERSION; /* reject the loader ♦/ 

/♦ 8, commit zo load new ITLM, this changes loader state ♦/ 
if (err « DSLRegister (DSModuleHandle 0 , DSVersionO, &ddsFuncs, 
fiemuFuncs , 

DSCanUnload. DSUnioad, &dslMemTag, dslCommandLine) ) 
return err; 

/* continue MLM initializacicns ♦/ 
/♦...*/ 

return 0 ; 

} 
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Tabic 5 - Code Fragments Implementing DSLoader Response to Step 7 
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int DSLNegotiateVer3ions(uint32 dsVersion,- uint32 •dslVersion, 
uint32 TegisteredDSVersion) 



{ 



•dslVersion = INTERNAL.VERSION; 
TegisteredDSVersion = registeredVersion; 
dsVersion = dsVersion; 

recurn acC EPTABLE.DS.VERS ION (dsVersion) ? 0: ERR.INVM-ID.DS.VERSION; 



As indicated by the above method, the computer progran^ providing services to a 
distributed directory can be dynamically updated without intenupdon of directory services. Thus, 
1 5 cridcal directory related services can be updated and new service enhancements can be added 
without interruption. 

Although one embodiment of the invcndon has been illustrated and described, various 
modifications and changes may be made by those skilled in the an without departing from the 
spirit and scope of the invention. 
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Claims 

1. A method, in a computer network, of dynanaically updating an old computer module with 
a new computer, comprising the steps of: 

a. receiving a request to update an old computer module; 

b. calling a loader computer module, which routes requests from the old computer 
module, having the basic functionality of the old computer module; 

c. loading a new computer module to replace the old computer module; and 

d. making active the new computer module and making inactive the old computer 
module. 

2. A method as recited in claim 1, whereby the new computer module is a more current 
version of the old computer module. 

3. A method as recited in claim I, further comprising the step of: checking that the request to 
update has valid authorization prior to calling the loader computer module. 

4. A method as recited in claim K further comprising the step of: checking that the new 
computer module is compatible with the old computer module prior to unloading the old 
computer module. 

5. A method as recited in claim U whereby the old and new computer modules arc NetWare 
loadable modules. 

6. A method as recited in claim 1 , whereby the old and new computer modules provide 
directory services. 

7. A method, in a computer network, of dynamically updating an old computer module with 
a new computer module, comprising the steps of; 

a. receiving a request to update an old computer module; 

b. calling a loader computer module, which routes requests from the old computer 
module, having the basic functionality of the old computer nriodule; 

c. loading a new computer module to replace the old computer module; 
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d. checking that the new computer module is compatible with the old computer 
module; and 

e. making active the new computer module and making inactive the old computer 

5 module if the new computer module is compatible with the old computer module. 

8. A method as recited in claim 7, whereby the new computer module is a more current 
version of the old computer module. 

10 9. A method as recited in claim 7, further comprising the step of: checking that the request to 
update has valid authorizadon prior to calling the loader computer module. 

10. A method as recited in claim 7, whereby the old and new computer modules are NetWare 
loadable modules. 

15 

11. A method as recited in claim 7. whereby the old and new computer modules provide 
directory services. 

12. A method of dynamically updating an old computer module being used on a server in a 
20 client/server network with a new computer module, comprising the steps of: 

a. receiving! a request to update an old computer module; 

b. calling a^lpadcr computer module, which routes requests from the old computer 
module, having the basic functionality of the old computer module; 

c. loading a new computer module to replace the old computer module; 

25 d. checking that the new computer module is compatible with the old computer 

module; and 

e. making active the new computer module and making inactive the old computer 

module if the new computer module is compatible with the old computer module. 

30 13. A method as recited in claim 12, whereby the new computer module is a more current 
version of the old computer module. 
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14. A method as recited in claim 12, further comprising the step of: checking that the request 
to update has valid authorization prior to calling the loader computer module. 



15. A method as recited in claim 12. whereby the old and new computer modules are 
NetWare loadable modules. 

16. A method as recited in claim 12, whereby the old and new computer modules provide 
directory services. 
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